The present disclosure generally relates to the field of computerized process control. More particularly, the present disclosure relates to a secure architecture for a platform independent executing of process control operation and applications. Most particularly, the present disclosure relates to an adaptive process control system for independent steering of plant control systems, wherein a plant associated with the plant control system includes a plurality of interlocked elements of one or more operational unit of the plant. In these systems, the operation of the operational units are controlled by the plant control system via the elements interlocked to the plant control system. Finally, the disclosure is related to a generalized human machine interface based on the adaptive process control system.
In the last decade, significant advances in industrial process control technology have vastly improved all aspects of factory and plant operation. Before today's modern industrial process control systems, industrial processes were operated and controlled by humans and rudimentary mechanical controls. As a consequence, the complexity and degree of control over a process was limited by the speed with which a human could ascertain a present status of various process state variables, compare the current status to a desired operating level, calculate a corrective action (if needed), and implement a change to a control point to affect a change to a state variable. Improvements to the process control technology were enabling larger and more complex industrial processes to be controlled via programmed control processors. Control processors execute control and/or steering programs that read process status variables, execute instruction commands associated with control algorithms based upon the status variable data and desired set point information to render output values for the control points in industrial processes. Such control processors and programs support a substantially self-running industrial process. In spite of the ability of industrial processes to operate under the control of programmed process controllers at previously established operational parameters without human intervention, supervisory control and monitoring of control processors and their associated processes is desirable. Such oversight is provided by both humans and higher-level control programs at an application/human interface layer of a multilevel process control network. Such oversight is generally desired to verify proper execution of the controlled process under the lower-level process controllers and to configure the set points of the controlled process.
Manufacturing and process control systems are modified due to changes in the process control devices and the processes themselves. Thus, it is important to provide means for quickly configuring/re-configuring without touching unchanged portions of the system. It is also important to provide means for making such changes while minimizing disruptions to the operation of the industrial process, e.g., minimizing the time that the process stands idle. Further, in view of the need to continually improve supervisory process control and process/manufacturing information systems, there is a strong desire to not be locked into a single architecture for a supervisory process control and manufacturing information system. Process control systems change and it is desirable to have higher-level systems that adapt to such changes regardless of their magnitude. Furthermore, less flexible supervisory process control and manufacturing information system offerings require designers of process control installations to take into consideration the long-term requirements of an application because of the relative inflexibility of the application to modifications once it is installed. Such application inflexibility of plant control systems is undesirable though at the present point inevitable in the conservative industrial control systems market. The process control industry tends to pilot, and often the designers are not fully aware of the full extent and form of the automation that will ultimately be incorporated in a final installation. Later in the life of a plant, when new functionality is added the new control system components leverage or merge existing systems. In such instances where the process control system has changed significantly, there are advantages to incorporating a different architecture into the installed supervisory process control application. In prior art systems, the whole mostly manufacturer-specific plant control systems has to be costly rebuild by programming experts of the specific manufacturer.
An important feature of modern plant control systems are the so-called PLCs, i.e. the programmable logic controllers. The programmable controller is a electronic, digital processor unit used for automation of typically industrial electromechanical processes, such as control of machinery on factory assembly lines, steered robot production lines, or light fixtures. PLCs are used in many industries and machines. PLCs are designed for multiple analogue and digital inputs and output arrangements, extended temperature ranges, immunity to electrical noise, and resistance to vibration and impact. Programs to control machine operation are typically stored in battery-backed-up or non-volatile memory. A PLC is a so-called hard real-time system since output results must be produced in response to input conditions within a limited time, otherwise unintended operation will result. Before the development of PLCs, control, sequencing, and safety interlock logic for automated manufacturing lines etc. were mainly composed of relays, cam timers, drum sequencers, and dedicated closed-loop controllers. However, for more complex processes, there were hundreds or thousands needed of them, and the process for updating such facilities for the yearly model change-over was immensely time consuming and expensive, as electricians needed to individually rewire the relays to change their operational characteristics. With regard to the programmable aspect of the PLC, a PLC is more or less a small processor-based device with a built-in operating system. This operating system is highly specialized to handle the discussed incoming events in real time, i.e., at the time of their occurrence. The PCL is user programmable, allowing to control the operation of an associated plant or the like, whereas the PLC has said input lines where sensors are connected to notify upon events (e.g. temperature above/below a certain level, liquid level reached, etc.), and output lines to signal any reaction to the incoming events (e.g. start an engine, open/close a valve, etc.). PLC uses languages as e.g. “Relay Ladder or RLL (Relay Ladder Logic). As the name “Relay Ladder Logic” implies, the control logic of the earlier days, which was built from relays, is being simulated by the structure of the instruction commands of the RLL. Other instructions command structures for PLC of the state of the art are e.g. called “sequential function chart”, “functional block diagram”, “structured text”, or “instruction list”.
Thus, PLCs are devices for controlling or regulating machinery or industrial installations. The elements employed therefor are usually housed in what are referred to as modules, with a module being defined as a self-contained object that can in turn consist of individual subassemblies and components. A module is thus a constituent part of an industrial installation or automation system and serves, by means of its programmable logic controller, to control or regulate the relevant equipment and machinery belonging to the installation. Modules are the interfaces to industrial processes. A range of modules enables all kinds of functions to be accommodated on a modular basis. Modules thus support a wide variety of technological tasks and offer extensive communication possibilities. A module's practical deployment requires relevant components of the automation installation or system to be electrically connected to the module. For example, it is necessary for various sensors and actuators that are used for the purpose of automating an installation to be connected to the modules that are used for providing the control.
As mentioned, PLCs are typically used to control machinery. Control sequences to be performed by PLCs consists in instructional commands on instructions to turn on and off outputs based on input conditions and the internal control sequence. In contrast to normal programs, PLC control sequences are designed to be programmed once, and run repeatedly as needed. In fact, PLCs can control not only simple devices such as a garage door opener, but a whole building or plant, including switching lights on and off at certain times, monitoring a custom built security system, etc. However, PLCs normally are found inside of a machine in an industrial environment. A PLC can run an automatic machine for years with little human intervention. They are designed to withstand most harsh environments.
As mentioned above, the PLC structure still relays on the historic control of machines by relays. When the first electronic machine controls were designed, they used relays to control the machine logic (i.e. press “Start” to start the machine and press “Stop” to stop the machine). Though, a machine can need a wall covered by relays to control all of its functions, this basic technology is almost completely failure resistant. There are only a few limitations and disadvantage to this type of machine control, as (i) relays failure, (ii) the delay when the relay turns on/off, and (iii) there is a huge amount of relays needed to design/wire/troubleshoot. PLCs overcomes these limitations of relays setup by its machine-controlled operation.
However, also PLCs have disadvantages. In the recent years, PLCs were becoming more and more intelligent. PLCs have been integrated into electrical communications (e.g. data transmission networks). So, all the PLCs in an industrial environment can be plugged into a network, which is usually hierarchically organized. The PLCs are then supervised by a control center. There exist many proprietary types of networks and process control systems. One type, which is widely known, is SCADA (Supervisory Control and Data Acquisition). However, most of the PLC still follows manufacture-proprietary designs. In general, a PLC is a purpose-built machine control processor driven device designed to read digital and analog inputs from various sensors, execute a user defined logic command sequence, and write the resulting digital and analog output values to various output elements like hydraulic and pneumatic actuators, indication lamps, solenoid coils, etc. As for the scan cycle, exact details vary between manufacturers, but most PLCs follow a ‘scan-cycle’ format. PLC's overhead includes testing I/O module integrity, verifying that the user command sequence logic has not changed, that the control unit itself has not locked up (e.g. via a watchdog timer), and any other necessary communications. Communications may include traffic over the PLC programmer port, remote I/O racks, and other external devices such as HMIs (Human Machine Interfaces). For the PLCs input scan, a snapshot of the digital and analog values present at the input cards is saved to an input memory table. For the logic execution, the user command sequence, i.e. program or algorithm, is scanned element by element, and sequentially operated until the end of the sequence, whereas resulting values are written to an output memory table. In PLCs, diagnosis and communication is used in different ways with variations in the use of logics, analytics, and experience to determine “cause and effect”. Mostly, in PLC engineering, it is used to determine the causes of symptoms, mitigations, and solutions, which are then communicated to the input module and/or used to send appropriate messages to the output module for any incorrect data files variations. Finally, for the output scan, values from the resulting output memory table are written to the output modules. Once the output scan is complete the process repeats itself until the PLC is powered down. The time it takes to complete a scan cycle is called the scan cycle time ranging from hundreds of milliseconds (typically on older PLCs, and/or PLCs with very complex programs) to only a few milliseconds on newer PLCs, and/or PLCs executing short, simple code. Apart from these general features, which can be found by almost all PLCs, already the basic command instructions vary widely in their specific nomenclature and operational details between PLC manufacturers. In addition, often implementation details evolve from generation to generation. It is a major disadvantage of the prior art system, that especially for inexperienced PLC operators or programmer, it is quasi impossible to keep the nomenclature straight from manufacturer to manufacturer. Thus, there is a strong dependency to the manufacturer of the PLC to keep the operation of a system or plant, which is operated by the corresponding PLCs, running and up-to-date. So much the worst, if even only very simple parts have to be replaced, complemented, cut down or scaled, expensive operators form the manufacturer have to be paid to modify or adapt the PLC command instruction sequence.
SCADA (Supervisory Control and Data Acquisition), as mentioned above, generally refers to a system operating with coded signals over communication channels to provide control of remote equipment, as PLCs, thereby using typically one communication channel per remote station. SCADA control systems may be combined with a data acquisition system by adding the use of coded signals over communication channels to acquire information about the status of the remote equipment for display or for recording functions (cf. B. Galloway et al., Introduction to Industrial Control Networks, IEEE Communications Surveys and Tutorials, 2012, in the following incorporated by reference). SCADA refers to a special type of industrial control system (ICS). Industrial control systems are processor-based systems that monitor and control industrial processes existing in the physical world. However, SCADA systems distinguish from other ICS systems by being able to hold large-scale processes that can include multiple sites, and large distances. These processes include industrial, infrastructure, and facility-based processes, whereas (i) industrial processes include manufacturing, production, power generation, fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes, (ii) infrastructure processes include inter alia water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical power transmission and distribution, wind farms, civil defense siren systems, and large communication systems, and (iii) facility processes occur both in public facilities and private ones, including buildings, airports, ships, and space stations. These processes can monitor and control heating, ventilation, and air conditioning systems (HVAC), access, and energy consumption etc.
SCADA systems typically include or are connected to the following subsystems: (i) Remote terminal units (RTUs) connect to sensors in the process and convert sensor signals to digital data. RTUs have telemetry hardware capable of sending digital data to the supervisory system, as well as receiving digital commands from the supervisory system. RTUs can have embedded control capabilities such as ladder logic in order to accomplish Boolean logic operations, (ii) programmable logic controller (PLCs), as already discussed above, connect to sensors in the process and convert sensor signals to digital data. PLCs have more sophisticated embedded control capabilities (typically one or more IEC 61131-3 programming languages) than RTUs. PLCs do not have telemetry hardware, although this functionality can be installed alongside. PLCs are sometimes used in place of RTUs as field devices because they are more economical, versatile, flexible, and configurable, (iii) a telemetry system is typically used to connect PLCs and RTUs with control centers, data warehouses, and the enterprise. Examples of wired telemetry media used in SCADA systems include leased telephone lines and WAN circuits. Examples of wireless telemetry media used in SCADA systems include satellite (VSAT), licensed and unlicensed radio, cellular and microwave, (iv) at least one data acquisition server, i.e. a software driven module which uses industrial protocols to connect software services, via telemetry, with field devices such as RTUs and PLCs. It allows clients to access data from these field devices using standard protocols, (v) a human-machine interface (HMI), which is the apparatus or device which presents processed data to a human operator, and through this, the human operator monitors and interacts with the process. The HMI is a client that requests data from a data acquisition server, (vi) a so called software-driven Historian module which accumulates time-stamped data, Boolean events, and Boolean alarms in a database which can be queried or used to populate graphic trends in the HMI. The historian is a client that requests data from a data acquisition server, (vii) a supervisory processor-based system, gathering (acquiring) data on the process and sending commands (control) to the SCADA system, (ix) communication infrastructure connecting the supervisory system to the remote terminal units, and (x) typically various processes and analytical instrumentation. Thus, SCADA based systems allow providing centralized control systems which monitor and control entire sites, or complexes of systems spread out over large areas (anything from an industrial plant to a nation). Most control actions are performed automatically by RTUs or by PLCs. Host control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process. The SCADA system now can allow operators to change the set points for the flow, and enable alarm conditions, such as loss of flow and high temperature, to be displayed and recorded. The feedback control loop passes through the RTU or PLC, while the SCADA system monitors the overall performance of the loop.
It is to be mentioned that digital computing units, as general-purpose programmable devices, were also applied to control of industrial processes. However, most of the plant control system have a manufacturer-specific interface and communication environment, so that accessing and steering of the plant control system typically requires specialist programmers, and stringent operating environmental control. Further, using a general-purpose computer for direct process control requires protecting the computer from the plant floor conditions. Thus, an industrial plant control computer must have several attributes: it must tolerate the environmental plant conditions, it must support discrete (bit-form) input and output in an easily extensible manner, it must not require years of training to use, and it must permit its operation to be monitored. The response time of any such system must be fast enough to be useful for control, wherein the required speed may vary according to the nature of the process. Since many industrial processes have timescales easily addressed by millisecond response times, modern (fast, small, reliable) electronics greatly facilitate building reliable controllers, especially because performance can be traded off for reliability. In summary, the prior art does not provide a generalized plant control system, which can be easily applied to any manufacturer-specific control system, platform independently, and which copes with the requirements of industrial plant control systems.
In the state of the art, OPC Unified Architecture (OPC UA) is know as an industrial M2M communication protocol for interoperability. OPC UA is developed by the OPC Foundation and is the successor to Open Platform Communications (OPC). OPC UA differs significantly from its predecessor. In contrast to the original OPC communications model, OPC-UA provides a cross-platform service-oriented architecture (SOA) for process control, while enhancing security and providing an information model. Thus, the OPC UA overcomes the proprietary problems of the original OPC, which was based on the Microsoft Windows only process exchange COM/DCOM, whereas DCOM is the short for Distributed Component Object Model, which is a proprietary Microsoft technology for communication among software components distributed across networked computers. DCOM, also referred as “Network OLE”, extends Microsoft's COM, and provides the communication frame under Microsoft's COM+ application server infrastructure. The addition of the “D” to COM refers to the use of DCE/RPC (Distributed Computing Environment/Remote Procedure Calls), and of the modified version of DCE/RPC, the Microsoft's enhanced version MSRPC (Microsoft Remote Procedure Call).
As mentioned, the OPC UA architecture is a service-oriented architecture (SOA) and is based on different logical levels. OPC Base Services are abstract method descriptions, which are protocol independent and provide the basis for OPC UA functionality. The transport layer puts these methods into a protocol, which means it serializes/deserializes the data and transmits it over the network. Two protocols are specified for this purpose. One is a binary TCP protocol, optimized for high performance and the second is Web service-oriented. The OPC information model is a Full Mesh Network based on nodes, whereas the nodes can include any kind of meta information. The OPC UA network nodes are treatable similar to objects in an object-oriented programming (OOP). Such objects can include attributes for read access (DA, HDA), methods, and triggered events that can be transmitted (AE, DataAccess, DataChange). Nodes hold for process data as well all other types of metadata. Therefore, OPC UA provides two core elements. First of all, the Microsoft Windows-specific protocol DCOM, which was the basis of the predecessor OPC, is replaced by open, platform-independent protocols with integrated security mechanisms. Secondly, the OPC features, such as Data Access, Alarms & Events and Historical Data Access, are transported in an object-oriented model and supplemented by additional features, such as methods and type systems. As a result, the OPC UA interface can be directly integrated into systems on arbitrary platforms with different programming languages, and arbitrary complex systems can captured completely with OPC UA. The object-oriented rules according to which the address space of an OPC UA server is structured and the OPC UA interface for accessing takes a form that OPC UA can be regarded as a network-capable programming language. However, note that OPC UA becomes specialized for automation technology through specific information models such as Data Access, Alarms & Conditions, Historical Access and Programs.
OPC UA consists of a list of specifications with the described basic functions and the information models based on these functions, such as Data Access and Alarms & Conditions. Specifications that define further information models beyond that are normally referred to as Companion Specifications. In the prior art, various OPC UA Companion Specifications were developed defining an information model for special branches of industry or areas of application. Example for such Companion Specifications are the specification OPC UA for Analyzer Devices (ADI), which was created on the basis of customer requirements and developed by a working group of OPC members within the OPC Foundation, or the information model OPC UA for IEC 61131-3, which was created with PLCopen defining an OPC UA information model for a standard outside the OPC Foundation. Finally, to use OPC UA for steerable or programmable devices, there exist a model for the configuration of hardware and software components, which was created in the common working group of OPC Foundation, Profibus User Organization (PNO), HART Foundation, Fieldbus Foundation (FF) and Field Device Tool (FDT) for the standardized configuration of field devices. This base model was released by the OPC Foundation as an independent information model and, in some cases, did serve as the basis for further standards such as OPC UA for Analyzer Devices and OPC UA for IEC 61131-3. The information model defines base types for configurable components and devices, it defines concepts for the logical grouping of parameters, methods and components and it defines points of entry in the OPC UA server address space. Besides that, information for the identification of devices and the available protocols is defined. However, one of the main drawbacks of the OPC UA remains in the fact that OPC UA allows only to handle and communicate structured data from one OPC UA client to another OPC UA client. Thus, OPC UA only provides a mere data transport container without allowing to directly control or steer any remote devises, associated with an OPC UA client within the OPC UA network.